Attribute Auto-population

Hi all,
Is there a way you can auto-populate ennumeration type attributes? For example, where an object is a Heading, it will automatically insert 'N/A' into an attribute called 'Verification Method' (on screen refresh). But where an object is a requirement it will allow you to select 'Verification Method' from the drop down menu?

I'm sure we had this in a previous company I worked for but can't figure it out from the DXL Reference Manual.

Any help gratefully received!

Thanks -lumish
lumish - Tue May 29 04:15:26 EDT 2012

Re: Attribute Auto-population
SystemAdmin - Tue May 29 19:32:15 EDT 2012

A semi-automatic method to consider is to create a DXL Attribute that uses conditional logic to modify the values of other attributes. Triggers could possibly work as well but I'll leave that to others who know Triggers better than me.

The down side is that the code in the DXL Attribute is only executed if the DXL Attribute itself is visible in a View. So Views that display attributes that require auto population will also need to display the DXL Attribute. The DXL Attribute could conceivably be included in the default opening View so that it's executed on opening but users can override that with their own personal default opening view, and it's just generally advisable not to have DXL Attributes in the default opening View anyway.

To avoid unexpected modifications being applied and "Attribute DXL Failed" errors being reported, the DXL code will need to be fairly robust, so think carefully about what the possible exception events are that need to be accounted for in the code - for example, perform an up front check to confirm that the attributes that will be auto populated do actually exist. Include a check that the user can write to the module (use canWrite(m)), this will avoid DXL errors being raised if the module is opened in Read-only or Shareable Edit mode (although in Shareable Edit mode, even when a user has locked a section for editing, the DXL Attribute will not execute as technically the user does not have write access to the whole module because canWrite(m) = false).
Paul Miller
Melbourne, Australia

Re: Attribute Auto-population
Mathias Mamsch - Wed May 30 03:19:08 EDT 2012

I think a clean way of solving this is to have a DXL attribute which will display N/A for headings and the value of another manually set enumeration attribute in case of a requirement. For example (note that the 'robustness' code is missing from that example:
  

// attr_dxl_verification_method.dxl 
string sType = probeAttr_(obj, "Requirement Type") 
if (sType == "Requirement") {
  string sValue = probeAttr_ (obj, "Manual Verification Method") 
  obj.attrDXLname = sValue
} else {
  obj.attrDXLname = "N/A"
}

 


You then incorporate two attributes in your view, one manual attribute (e.g. 'Manual Verification Method') where you can set the verification method, and the calculated "official" verification method from the DXL attribute. In your official views you will only show the calculated value, except for the guy who actually needs to fill the attribute (he will see both).

Maybe that helps, Regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Re: Attribute Auto-population
llandale - Wed May 30 12:01:32 EDT 2012

I think you want...
  • .. "N/A" to be the only valid value for non-requirement objects (such as headings). I think you should want "" nothing to be the only such valid value; as I think it looks far better in a report as eyes are not distracted to useless information.
  • .. "N/A" to be illegal for requirement objects.
  • .. "TBD" to be the default value for requirement objects.

  • So perhaps the Enumerations are "N/A", "TBD", "Test", "Demonstrate", "Analysis".

Here are some ill-formed random thoughts.
  • I wonder about a pre-save-attr trigger which checks the Object Type and determines if the proposed value is valid for that object. An invalid value will result in a check to see ..err.. guess how the value is being set; I wonder if it is being set manually when either "In Place Editing" is active or the "Object Properties Dialog" is showing. Illegal Manual edits result in some form of "You idiot" dialog box, other edits (such as dxl) just prevent the invalid value without ceremony.
  • I don't think the above handles the initial default value, such as when you create a new object.

-Louie